Pref locking in Mozilla Firefox/SeaMonkey
=========================================
To lock prefs in Firefox/SeaMonkey, you can't just do it from regular prefs files.  You have to define a 'general config' file and you can lock prefs in
there.  To define this 'general config' file, you need to use a regular pref.  At the time of writing, there's a bit of a bug that means the browser doesn't
scan all pref (.js) files in [FIREFOX_ROOT/SEAMONKEY_ROOT]/defaults/pref/.  So, you can't add this pref in a new prefs file (this bug will likely be fixed very
soon).  However, there is already a channel-prefs.js file in [FIREFOX_ROOT/SEAMONKEY_ROOT]/defaults/pref/ that can be modified and so you can add the 'general
config pref file' pref in there.  So, the pref you need to add is:

pref("general.config.filename", "mozilla.cfg");

Add it to channel-prefs.js, or if that bug is fixed, some new custom prefs file if you want.

That 'mozilla.cfg' will be looked for in the root dir for that installation - that should be the same dir as firefox.exe/seamonkey.exe is in, probably 2 dirs up
from the defaults/pref/ directory.  It needs to be there once you've defined that 'general config' pref or Firefox/SeaMonkey will complain that it can't read the
file, and fail to start.  The file that must be put there must be byte-shifted by 13 bytes, which can be done at this URL:
http://www.alain.knaff.lu/%7Eaknaff/howto/MozillaCustomization/cgi/byteshf.cgi

In case that URL stops working, you can also use the moz-byteshift.pl Perl script in this dir to do the shifting.  If your input file is 'mozilla.txt',
you run something like this (on a bash prompt) to get an output of a byte-shifted mozilla.cfg file:
./moz-byteshift.pl -s 13 <mozilla.txt >mozilla.cfg

As for what the mozilla.cfg file (before being byte shifted) has to look like, check out the example 'mozilla.txt' file in this dir.  Not that it
MUST start with one comment line (god knows why), and then the pref locking directives can begin.
Also check out the 'mozilla.cfg files' directory for various different mozilla.cfg pref locking check files (the .txt) ones, and their
already-byte shifted .cfg files, which can be copied to the Firefox root dir and renamed mozilla.cfg if you want.



Specifically, locking to 'working online' or 'working offline'
==============================================================
Now, this is where the Firefox/SeaMonkey behaviour gets seriously weird IMHO.  Here's how it works, from what I can tell.  There are 2 prefs that determine things;
they are 'browser.offline', and 'network.online'.

'browser.offline' is usually a 'flag' pref.  That is, when you change it, it actually DOESN'T do anything to change your 'working online/offline' status.
You have to run some Javascript to actually change that status, but when you do, 'browser.offline' gets updated.

HOWEVER, this pref DOES determine what the browser's INITIAL state is for 'working online/offline', so if we've done a:
lockPref("browser.offline", true);
... then the browser will start in 'working offline' mode.  However, the user can just flip things back to working online again, by default.

But what if network admins wanna lock the user into working online/offline?  The fact that this pref is locked should determine that
the 'working online/offline' status can't be changed, right?  Well, for some reason it doesn't work that way.  You CAN lock a user's 'working online/offline'
status, but the way you do THAT is to lock a DIFFERENT pref - the 'network.online' pref.  It *doesn't matter what this pref is locked to*.  It can be
locked to true or false.  All that is checked is WHETHER this pref is locked.  :-)  My extension emulates this Firefox/SeaMonkey behaviour, then, and locks
(greys out) its interface if it determines that the network.online pref is locked (though it cares not what the value of network.online is locked TO).

So, in short:
browser.offline: its value determines the browser's startup 'working online/offline' status.
                 whether it's locked to a value or not makes no difference.

network.online:  its value makes no difference.
                 whether it's locked or not determines whether the user is able to toggle between working online/offline modes.

Actually, just to muddy the waters a bit more, I think the network.online pref's locked status really just *suggests* whether a user's ability to toggle
between online/offline modes should be locked.  My extension is just 'behaving responsibly' by respecting whether it's locked or not, but it could choose to
toggle online/offline mode whether or not the network.online pref was locked.
